Embracing Change with Extreme Programming

0018-9162/99/$10.00 © 1999 IEEE 70 Computer I n the beginning was the waterfall (Figure 1a). We would get the users to tell us once and for all exactly what they wanted. We would design the system that would deliver those features. We would code it. We would test to make sure the features were delivered. All would be well. All was not well. The users didn’t tell us once and for all exactly what they wanted. They didn’t know. They contradicted themselves. They changed their minds. And the users weren’t the only problem. We programmers could think we were making great progress only to discover three-fourths of the way through that we were one-third of the way through. If long development cycles were bad because they couldn’t adapt to changes, perhaps what we needed was to make shorter development cycles. As Figure 1b shows, the waterfall begat iterations. The waterfall model didn’t just appear. It was a rational reaction to the shocking measurement that the cost of changing a piece of software rose dramatically over time. If that’s true, then you want to make the biggest, most far-reaching decisions as early in the life cycle as possible to avoid paying big bucks for them. The academic software engineering community took the high cost of changing software as a challenge, creating technologies like relational databases, modular programming, and information hiding. What if all that hard work paid off? What if we got good at reducing the costs of ongoing changes? What if we didn’t have to settle for taking a cleaver to the waterfall? What if we could throw it in a blender? Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities—a little at a time—throughout development. Cover Feature Embracing Change with Extreme Programming